Medical image management system

ABSTRACT

Medical image management system to allow any conventional Internet browser to function as a medical workstation. The system may be used to convert medical images from a plurality of image formats to browser compatible format. The Invention also relates to methods to manipulate digital medical images in such a way that multiple imaging modalities from multiple different vendors can be assembled into a database of Internet standard web pages without loss of diagnostic information.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.09/742,575 filed on Dec. 20, 2000, now U.S. Pat. No. 6,934,698.

FIELD OF THE PRESENT INVENTION

The Present Invention relates to medical imaging. Specific exemplaryembodiments discussed relate to cardiac medical imaging.

BACKGROUND OF THE PRESENT INVENTION

The description of the references in this Section is not intended toconstitute an admission that any reference referred to herein is “PriorArt” with respect to the Present Invention, unless specificallydesignated as such.

Medical imaging is important and widespread in the diagnosis of disease.In certain situations, however, the particular manner in which theimages are made available to physicians and their patients introducesobstacles to timely and accurate diagnoses of disease. These obstaclesgenerally relate to the fact that each manufacturer of a medical imagingsystem uses different and proprietary formats to store the images indigital form. This means, for example, that images from a scannermanufactured by General Electric Corp. are stored in a different digitalformat compared to images from a scanner manufactured by Siemens MedicalSystems. Further, images from different imaging modalities, such as, forexample, ultrasound and magnetic resonance imaging (MRI), are stored informats different from each other. Although it is typically possible to“export” the images from a proprietary workstation to anindustry-standard format such as “Digital Imaging Communications inMedicine” (DICOM), Version 3.0, several limitations remain as discussedsubsequently. In practice, viewing of medical images typically requiresa different proprietary “workstation” for each manufacturer and for eachmodality.

Currently, when a patient describes symptoms, the patient's primaryphysician often orders an imaging-based test to diagnose or assessdisease. Typically, days after the imaging procedure, the patient'sprimary physician receives a written report generated by a specialistphysician who has interpreted the images. The specialist physician,however, typically has not performed a clinical history and physicalexamination of the patient and often is not aware of the patient's othertest results. Conversely, the patient's primary physician typically doesnot view the images directly but rather makes a treatment decision basedentirely on written reports generated by one or more specialistphysicians. Although this approach does allow for expert interpretationof the images by the specialist physician, several limitations areintroduced for the primary physician and for the patient, such as, forexample:

-   -   (1) The primary physician does not see the images unless he        travels to another department and makes a request;    -   (2) It is often difficult to find the images for viewing because        there typically is no formal procedure to accommodate requests        to show the images to the primary physician;    -   (3) Until the written report is forwarded to the primary        physician's office, it is often difficult to determine if the        images have been interpreted and the report generated;    -   (4) Each proprietary workstation requires training in how to use        the software to view the images;    -   (5) It is often difficult for the primary physician to find a        technician who has been trained to view the images on the        proprietary workstation;    -   (6) The workstation software is often “upgraded” requiring        additional training;    -   (7) The primary physician has to walk to different departments        to view images from the same patient but different modalities;    -   (8) Images from the same patient but different modalities cannot        be viewed side-by-side, even using proprietary workstations;    -   (9) The primary physician cannot show the patient his images in        the physician's office while explaining the diagnosis; and    -   (10) The patient cannot transport his images to another        physician's office for a second opinion.

It would be desirable to allow digital medical images to be viewed bymultiple individuals at multiple geographic locations without loss ofdiagnostic information.

“Teleradiology” allows images from multiple scanners located at distantsites to be transferred to a central location for interpretation andgeneration of a written report. This model allows expert interpreters ata single location to examine images from multiple distant geographiclocations. Teleradiology does not, however, allow for the examination ofthe images from any site other than the central location, precludingexamination of the images by the primary physician and the patient.Rather, the primary physician and the patient see only the writtenreport generated by the interpreters who examined the images at thecentral location. In addition, this approach is based on specialized“workstations” (which require substantial training to operate) to sendthe images to the central location and to view the images at the centrallocation. It would be advantageous to allow the primary physician andthe patient to view the images at other locations, such as the primaryphysician's office, at the same time he/she and the patient see thewritten report and without specialized hardware or software.

In principle, medical images could be converted to Internet Web Pagesfor widespread viewing. Several technical limitations of currentInternet standards, however, create a situation where straightforwardprocessing of the image data results in images which transfer across theInternet too slowly, lose diagnostic information or both. One suchlimitation is the bandwidth of current Internet connections which,because of the large size of medical images, result in transfer timeswhich are unacceptably long. The problem of bandwidth can be addressedby compressing the image data before transfer, but compression typicallyinvolves loss of diagnostic information. In addition, due to the size ofthe images the time required to process image data from an originalformat to a format which can be viewed by Internet browsers isconsiderable, meaning that systems designed to create Web Pages “on thefly” introduce a delay of seconds to minutes while the person requestingto view the images waits for the data to be processed. Workstationsallow images to be reordered or placed “side-by-side” for viewing, butagain, an Internet system would have to create new Web Pages “on thefly” which would introduce further delays. Finally, diagnosticinterpretation of medical images requires the images are presented withappropriate brightness and contrast. On proprietary workstations theseparameters can be adjusted by the person viewing the images but controlof image brightness and contrast are not features of current Internetstandards (such as, for example, http or html).

It is possible to allow browsers to adjust image brightness andcontrast, as well as other parameters, using “Java” programming. “Java”is a computer language developed by Sun Microsystems specifically toallow programs to be downloaded from a server to a client's browser toperform certain tasks. Using the “Java” model, the client is no longersimply using the browser to view “static” files downloaded from theserver, but rather in addition the client's computer is running aprogram that was sent from the server. There are several disadvantagesto using “Java” to manipulate the image data. First, the user must waitadditional time while the “Java” code is downloaded. For medical images,the “Java” code is extensive and download times are long. Second, theuser must train to become familiar with the controls defined by the“Java” programmer. Third, the user must wait while the “Java” codeprocesses the image data, which is slow because the image files arelarge. Fourth, “Java” code is relatively new and often causes browsersto “crash.” Finally, due to the “crashing” problem “Java” programmerstypically only test their code on certain browsers and computers, suchas Microsoft Explorer on a PC, precluding widespread use by owners ofother browsers and other computer platforms.

Wood et al., U.S. Pat. No. 5,891,035 (“Wood”), the contents of which arehereby incorporated by reference in their entirety, describe anultrasound system which incorporates an http server for viewingultrasound images over the Internet. The approach of Wood, however,creates Web Pages “on the fly,” meaning that the user must wait for theimage processing to complete. In addition, even after processing of theimage data into a Web Page the approach of Wood does not provide forprocessing the images in such as way that excessive image transfer timesdue to limited bandwidth are addressed or provide for“brightness/contrast” to be addressed without loss of diagnosticinformation. In addition, the approach of Wood is limited to ultrasoundimages generated by scanners manufactured by a single company, and doesnot enable viewing of images from modalities other than ultrasound.

FIG. 1 summarizes a common prior art approach currently used bycompanies to serve medical images to Internet browsers (e.g., GeneralElectric's “Web-Link” component of their workstation-based “PictureArchiving and Communication System” (PACS)). As can be seen in FIG. 1,serial processing of image data “on the fly” combined with extensiveuser interaction results in a slow, expensive, and unstable system.

Referring to FIG. 1, after a scanner acquires images (Step 100) a usermay request single image as a webpage (Step 200) whereby the image datais downloaded (Step 300) to allow the user to view a single image withthe single image (Step 400). Steps 1000-1400 result in extensive userinteraction which results in the system being slow, expensive andunstable.

While the Present Invention relates to medical imaging generally, itwill be better understood within the discussion of exemplary embodimentsdirected toward cardiac imaging.

SUMMARY OF THE PRESENT INVENTION

The Present Invention proceeds from the realization that if medicalimages of different formats could be processed in such a way thatlimitations of current Internet standards could be overcome, anystandard Internet browser could be used as a diagnostic workstation toallow any medical image to be viewed from any location on earth withoutspecialized hardware or software. Once this goal has been achieved, thefollowing actions becomes possible:

-   -   (1) To notify the primary physician via e-mail or pager as soon        as the imaging has been completed;    -   (2) For the primary physician to view the images with a single        “double click”;    -   (3) To view the images at the same time the primary physician        and/or the patient reads the written report;    -   (4) To view images of the same patient but from different        modalities side-by-side;    -   (5) To view images of the same patient and same modality but        different time points side-by-side to assess the progression of        disease;    -   (6) For the primary physician to discuss the images over the        telephone with another physician who is viewing the same images        simultaneously at another location;    -   (7) To make diagnoses and clinical treatment plans from anywhere        in the World, including the physician's home;    -   (8) To discuss the images with the patient in the physician's        office or over the telephone with the patient at home;    -   (9) For the patient to present the images to another physician        for a second opinion; and    -   (10) For the patient to move to a different city/state/country        and have the images “move” with him/her.

Furthermore, once the standard Internet browser can be used as adiagnostic workstation, it becomes feasible to construct a Worldwidedatabase of medical images using a predefined hierarchical Internetaddressing structure. This structure would allow for the unique addressof all medical images for all persons throughout their lifetime.

Accordingly, one embodiment of the Present Invention is directed towarda method of managing medical images. A plurality of medical imagescreated by a plurality of medical imaging devices, each of whichprocesses the medical image using a unique image format, is received.The medical images are then converted to a common image format suitablefor display on a computer screen. Preferably the method comprisesposting the converted images for access via a client computer. Browsercompatible pages having embedded tags corresponding to the convertedimages are preferably generated and posted with the converted images.

Another embodiment of the Present Invention is directed towards amedical image database comprising images corresponding to a plurality ofdifferent modalities. The database is preferably organized in ahierarchical data structure where the data structure comprises a patientidentifier parameter and an image modality identifier parameter. Theimage identifier parameter is associated with at least one of theplurality of modalities. The patient identifier parameter is preferablyat a higher level in the hierarchical data structure than the imagemodality identifier parameter.

In one method of managing medical images according to the PresentInvention, images are pulled from a scanner in response to a userrequest. The pulled images are converted to a common image formatcompatible for display at a computer. The converted images are thenposted for display at a client computer. Preferably, the method includesdisplaying to a user at the client computer a selection comprisingimages associated with at least two different modalities. The methodalso preferably comprises simultaneously displaying on a screen amedical image to a first user at a first location and a second user at asecond location.

A medical image system, according to the Present Invention, comprises amedical image management system. In a preferred embodiment, the medicalimage management system comprises a transfer engine for receiving imagedata from a scanner; a converter engine connected to receive images fromthe transfer engine and convert the images to a browser compatibleformat; and a post engine connected to receive images from the converterengine and post the images for subsequent access by a user.

In a preferred embodiment, the converter engine comprises a decodingengine for extracting raw image data; and a physiologic knowledge engineadapted to receive data from the decoding engine. The physiologicknowledge engine adjusts the image quality and reduces the size of theimage data, which is then transferred to a post engine. The physiologicknowledge engine is primarily responsible for reducing the image filesize without loss of diagnostic data though other aspects of the PresentInvention are used to reduce file size while maintaining viability ofthe data. The encoding engine converts the image data to browsercompatible image data.

Other objects and advantages of the Present Invention will be apparentto those of skill in the art from the teachings herein.

BRIEF DESCRIPTION OF THE DRAWINGS

In the interest of enabling one of skill in the art to practice thePresent Invention, exemplary embodiments are shown and described. Forclarity, details apparent to those of skill in the art and reproduciblewithout undue experimentation are generally omitted from the drawingsand description.

FIG. 1 depicts a prior art method for user to view images from ascanner;

FIG. 2 depicts a block diagram of an imaging managing system accordingto an embodiment of the Present Invention;

FIG. 3 depicts a system overview of an embodiment of the PresentInvention for providing a user with images from a scanner;

FIG. 4A depicts steps for affecting transfer of images from a scanner;

FIG. 4B depicts an alternate method for obtaining images from a scannervia a disk having the images stored thereon;

FIG. 5A depicts a method for extracting raw pixel data from a standardimage data format;

FIG. 5B depicts a method for extracting raw pixel data from anon-standard image format;

FIG. 6 depicts a method for reducing image data files without loss ofdiagnostic data;

FIG. 7A describes a method for reducing image data file size withoutloss of diagnostic information;

FIG. 7B pictorially depicts selecting a bright pixel in a diagnosticsearch region;

FIG. 7C depicts the diagnostic search area in both representativethumbnail size and full screen size with corresponding file sizesindicated;

FIG. 8 depicts steps for converting the image to a browser compatibleformat;

FIG. 9 depicts a method for posting the browser compatible image to adatabase;

FIG. 10 is a diagram of a file structure for a web compatible database;

FIG. 11 depicts a possible interface structure for accessing webcompatible database via the Internet;

FIG. 12 depicts a method for displaying an image stored on a webcompatible database accessible via the Internet;

FIG. 13 depicts a selection of modalities for a patient, namely Doe,John;

FIG. 14 shows a image identification data obtained from a separate filedisplayed with the medical image;

FIG. 15 depicts a web page comprising ECG medical image data;

FIG. 16 depicts MRI medical image; and

FIG. 17 depicts SPECT medical image data.

DESCRIPTION OF EXEMPLARY EMBODIMENTS OF THE PRESENT INVENTION

The Present Invention is discussed in relation to imaging with specificapplications discussed in relation to cardiac images; however, otheruses will be apparent from the teachings disclosed herein. The PresentInvention will be better understood from the following detaileddescription of exemplary embodiments, with reference to the attachedfigures, wherein like reference numerals and characters refer to likeparts, and by reference to the following Claims.

It will be apparent to one possessing ordinary skill in the art that thestructure, methods and systems described herein regarding a medicalimage management system are additionally and inherently applicable tothe management of multiple types of medical information, such as, forexample, medical imaging reports, electrocardiograms, medical testresults, patient demographics, clinic reports, procedure reports,in-patient summary reports and the like.

The herein-described Present Invention has been constructed and testedon images of the heart acquired using a variety of modalities. Theimages have been pulled from commercial scanners, processed without lossof diagnostic information, adjusted with respect to brightness andcontrast, and posted on Internet Web Pages for viewing.

FIGS. 2 and 3 show the process in schematic form. In FIG. 2, a medicalimage management system 10 is connected via a Hospital Intranet or theInternet 12 to a number of browsers 14 (such as, for example, MicrosoftExplorer™ or Netscape Navigator™). The connection 12 to the browsers isused to: 1) Accept commands to pull images from the scanners 16; 2) Tonavigate through images which have already been posted as web pages; and3) To arrange and organize images for viewing. The medical imagemanagement system 10 is also connected to a number of medical imagingsystems (scanners) 16 via a Hospital Intranet or the Internet 12′. Theconnection 12′ to the scanners 16 is used to pull the images byInternet-standard file transfer protocols (FTP). Alternatively, imagescan be transferred to the system 10 via a disk drive or disk 18 (seeFIGS. 2 and 3).

Preferably the scanner, and hence modality, is associated with magneticresonance imaging, echocardiographic imaging, nuclear scintigraphicimaging (e.g., SPECT, or single photon emission computed tomography),positron emission tomography, x-ray imaging and combinations thereof.

Responsibility for the entire process is divided amongst a series ofsoftware engines. The processes of the transfer engine 20, decodingengine 22, physiologic knowledge engine 24, encoding engine 26 and postengine 28 (FIGS. 2 and 3) are preferably run automatically by computerand do not require the person using the browser, the user, to wait forcompletion of the associated tasks. The decoding engine 22, physiologicknowledge engine 24 and encoding engine 26 are, preferably, combined toform a converter engine. The post engine 28 sends an e-mailnotification, via an e-mail server 30 (FIG. 2) to the person submittingthe request when the computations are complete, thereby allowing therequester to do other tasks. Similarly, text messages could be sent to aphysician's pager. The time necessary for these computations depends onthe size of the images and the speed of the network, but was measuredfor the MRI images of FIG. 16 to be approximately 3 minutes over astandard Ethernet 10BASET line (10 Mbps) using a 400 MHz computer.

The transfer engine 20 is responsible for pulling the images from thescanner 16 for example, in response to a user request (Step 2010).(FIGS. 2 and 3, details in FIG. 4). Using previously recordedinformation such as, for example, a username and password (Step 2020),the transfer engine 20 logs into the scanner 16 over the Internet 12(Step 2030) and pulls the appropriate images from the scanner 16, usingstandard Internet FTP or DICOM commands (Step 2040). Alternatively,images can be acquired by the transfer engine 20 by use of a disk drive18 such as, for example, a CD-ROM drive (FIGS. 2-4) (Steps 2011-2022).When the transfer process is complete, all images from the scan willexist within the transfer engine 20 but are still in their originaldigital format. This format may be specific to the scanner 16manufacturer, or may be one of a variety of formats which are standardbut cannot be displayed by browsers, such as, for example, DICOM. Theimages are then passed to the decoding engine (Step 3000).

The decoding engine 22 (FIG. 5) is responsible for extracting the rawimage pixel data from the original, differing, non-Web compatibledigital formats that the transfer engine 20 acquired. In the case ofstandard formats, such as, for example, DICOM, this can be accomplishedby reading published file structures and writing computer code to readthis format (Steps 3010-3020). In the case of non-standard formats,successful extraction of the image data proceeds from the realizationthat all formats differ from each other mainly in the header region ofthe image file, i.e., the part which contains information like thepatient name, scan date, name of hospital, etc. (Steps 3011-3021.)Because the most important information such as patient name and scandate can be input via the web-based form pages upon submission (seeFIGS. 14-17, for example), extraction of the image data for non-standardformats can be accomplished by ignoring the header data entirely andreading only the image data. Typically, the image data are stored as aseries of pixel values starting at the upper left corner of the imageand proceeding across each row of pixels from left to right and thenrepeating this process for all rows of the image (i.e., top to bottom).

The physiologic knowledge engine 24 (FIG. 6) is responsible foradjusting image brightness and contrast, adjusting image magnification,adjusting movie frame speed and other image parameters important fordiagnosis (Step 4010-4020). The physiologic knowledge engine 24 is alsoresponsible for reducing the size of the images to allow acceptabletransfer times at current Internet bandwidths without loss of diagnosticinformation (Step 4030). These tasks are achieved in part by the use ofa priori knowledge of physiology, anatomy, the diagnostic question orany combination of the three. One aspect of this is the realization thatthe human eye is capable of distinguishing less than 256 distinct levelsof gray in a medical image, and that most of the field-of-view (FOV) ofthe image is not of diagnostic interest. The grayscale limitations ofthe human eye imply that any medical image can be compressed to 8-bitsof grayscale levels and that, if appropriately scaled, the resultingimage will have appropriate brightness/contrast without the need toadjust these using the Web browser (FIG. 7A, Step 4020). This isimportant because adjustment of brightness/contract by the browser isnot part of existing Internet standards. Another important piece of apriori information is that much of the FOV is not of diagnostic interest(Step 4030 and FIG. 7B). This implies that the images can be croppedwhich allows a significant reduction in the size of the image file. Thisis important because limitations of existing Internet bandwidths resultin excessive image transfer times if the file size is not reduced.

An example of how the physiologic knowledge engine 24 functions is givenin FIGS. 7A-7C for the specific case of MRI of the heart. In Step 4020,the region of the image which contains the organ of diagnostic interestis defined (e.g. the heart). For the general case of a group of imageswhich are intended to be played as a movie to depict time-varyingquantities (e.g. heart motion), the physiologic knowledge engine 24searches all movie frames for the single brightest pixel within thesearch region (e.g. within the heart). All pixels of all movie framesare then scaled such that the single brightest pixel within the searchregion of all frames equal 255 (e.g., 8-bit image). After this Step, theimage brightness/contrast are appropriate for the organ of interestwithout loss of diagnostic information.

In Step 4030, thumbnail movies are extracted for which the FOV isreduced by cropping the images to contain only the organ of interest(e.g., the heart). For a typical file size of 2,000 KB for a movie with16 frames, the processes herein described would result in a 20-foldreduction in movie file size for the thumbnails (to 100 KB) and 6-foldfor full FOV images (to 400 KB) (See FIG. 7C). These file sizes implythat every still-frame and every movie from an entire patient scan canbe transferred over the Internet as thumbnails in a few seconds.

In Step 4040, the frame rate is chosen to simulate real-time motion(e.g., a beating heart would have all frames play within one heart beator about 1 second). In Step 4050, full FOV images are created with amagnification which fills the user's entire screen because this is whata cardiologist would like to see for a heart image. Each thumbnail canbe “clicked” by the mouse to initiate transfer of the entire FOV forthat movie, also in a few seconds. Importantly, this is achieved withoutloss of diagnostic information, without the need to adjustbrightness/contrast, and without the need to adjust the frame rate ofthe movie. Step 4060 comprises adjusting other parameters, if warranted.When the physiologic knowledge engine 24 has completed these tasks onall images from a given patient, they are passed to the encoding engine26.

The encoding engine 26 (FIG. 8) is responsible for converting the imagesfrom the raw pixel format to a new format which can be displayed bybrowsers 14 (Steps 5010-5020). One such format is the graphicsinterchange format (GIF), which can be used to display images in grayscale or color with or without animation (movies). The conversion isachieved using published definitions of web-compatible image formats andwriting appropriate computer code. The images are then saved to disk andthe post engine 28 is called.

The post engine 28 (FIG. 9) is responsible for generating the html pageswithin which the images will be displayed (Steps 6010-6030). These htmlpages may contain coding to display text such as the patient name, examdate, etc. (Step 6040). In addition, the html page will containhtml-standard image tags which instruct the browser 14 to display theconverted images. The methods by which the html pages are constructedand the image tags embedded are standard to the Internet and arepublished elsewhere. The final responsibilities (Step 6050) of the postengine 28 are: 1) To transfer the completed html pages and the convertedimages to the Web-Compatible Database 32 (FIGS. 2 and 3, details FIG.10) located on the “http Server” 34 for viewing over the Internet; and2) To send e-mail notification to the physician (or technician) via thee-mail server 30 (FIG. 2) stating that the images have been posted; and3) providing the http address for the images within the e-mail messagesuch that the physician can “double-click” to immediately view theimages.

Once the images are posted as Web Pages, additional Web Pages can beused to allow the technician or physician to rearrange the order of theimages on the Web Page according to the diagnostic question. Forexample, echocardiographic images are often acquired before and after adrug to increase heart rate has been given (e.g., dobutamine). Theimages before and after the administration of dobutamine are best viewedside-by-side for comparison. Arranging the images side-by-side can beachieved by allowing the user to select images using html standard WebPage “forms.” The form data can then be submitted using Web-standardCommon Gateway Interface (CGI) protocols and processed by the serverusing a CGI program written specifically for this purpose. The CGIprogram could then create a new Web Page in which the image containersare arranged side-by-side and the html “image tags” are set to point tothe images defined by the user. Rearrangement of the images occurs veryquickly because the images do not require further processing or transferacross the Internet.

FIG. 11 shows how the Web-Compatible Database 32 of FIG. 10 can be usedas the basic building block of a Worldwide database which can beinterrogated from any location on earth, for example, using any browser14. In practice, some form of security such as password protection wouldbe provided to prevent unauthorized viewing of the image data.

As shown in FIG. 10, the database 32 is constructed as a hierarchicaldirectory-tree with the patient's name 36 at a higher level than themodality 38. Within each modality subdirectory, a series of directorieswith names corresponding to the scan date 40 would appear to allow forserial examinations over the patient's lifetime.

Using this type of structure, one can now define a hierarchical Internetaddressing system in which any image from any modality for any personacquired on any date will have an unique, pre-determined Internetaddress. For example, the hierarchical address could involve, first, theSocial Security Number of the patient, then the imaging modality,followed by the scan date (See FIG. 12, Step 7010, for example). Withthis scheme, if a child were born in the U.S. on 11 Jul. 2015, assigneda social security number of 123456789, and later scanned by MRI on 23Sep. 2027, everyone in the world would know, a priori, that those imageswill be located at, for example, Internet address:http://www.imagedatabase.com/usa/123456789/mri/23sep2027. Further, itis, also a priori, known that any MRI images of that patient takenanywhere, anytime in his/her lifetime are listed by scan date at:http://www.imagedatabase.com/usa/123456789/mri, and further that allimages of any modality that have ever been acquired of that patient inhis/her lifetime are listed at:http://www.imagedatabase.com/usa/123456789.

The section of the URL “www.imagedatabase.com” refers to the companyoffering to serve the images over the Internet. Such a company would notprocess the images in any way because the images have already beenprocessed as described herein. Rather, the sole function of such acompany is to provide computing hardware which reads the “static” imagedata from a hard disk and pushes the data over the Internet (note thatboth still-frame images and movies are contained in “static” computerfiles). Because the images are already stored in the format of InternetWeb Pages, no processing of the data is required resulting in maximumspeeds for image access and transfer and ensuring minimum cost for theoverall system.

In fact, specialized computers which are capable of no function otherthan reading from a hard disk and pushing the data over the Internetalready exist and could easily be assembled into a array of serversproviding access to an extremely large amount of data over the Internetfor minimum cost. For example, currently a commercial system of thistype provides 120 GB of storage for $3000. With 10 MB of image data perpatient scan (typical), this system would provide permanent Internetaccess to 12,000 complete MRI patient scans for a cost of 25 cents each(exclusive of electrical and maintenance costs). Importantly, this typeof World-wide database would be difficult if not impossible to constructif the processes described herein were not employed.

FIG. 12 shows how a user's request to view images (Step 7010) would beprocessed (Steps 7020-7040) by the World-wide database system of FIG. 11using the basic building block of FIG. 10. FIG. 13 shows the resultantWeb Page 40 displaying in response to a user sending a request to view“/Doe, John” via a browser 14. FIG. 14 shows the result of clicking on“Cath” 42 (see FIG. 13) followed by clicking on the scan date (notshown). Identification data 43 is displayed with the image 44corresponding to the examination data indicated. The html page 40′ andthe embedded images 44 are sent by the http server 34 to the browser 14.The images 44 can be still frames or movies depending on how they wereoriginally acquired by the scanner 16. In the case of movies, animatedGIF format can be used by the encoding engine 26. FIGS. 15, 16 and 17show the result of clicking on ECG, MRI, and SPECT, respectively. Thetime necessary to transfer the images 44 from the http Server 34 to thebrowser 14 will depend on the size of the images 44 and the speed of thenetwork, but was measured to be approximately 3 seconds for the entireset of MRI images of FIG. 16 over a standard ethernet 10BASET line (notethat the top row of MRI images in FIG. 16 are movies displaying heartcontraction).

Thus, using the Present Invention a database of images ban beconstructed with maximum Internet performance and without loss ofdiagnostic information. Importantly, the processes described hereinallow viewing of images from multiple modalities side-by-side by theprimary physician and/or the patient. Further, the database structurefacilitates the storage of image data from multiple modalities andmultiple scans over a patient's lifetime in a single location identifiedby the patient's name, social security number or other uniqueidentifier. This ability would be expected to significantly enhance theability of the primary physician to determine the course of action whichis in the best interest of the patient.

While the Present Invention has been particularly shown and describedwith reference to particular embodiments thereof, it will be understoodby those skilled in the art that various changes in form and detail maybe made therein without departing from the spirit and scope of thePresent Invention. The scope of the Present Invention, as claimed, isintended to be defined by following Claims as they would be understoodby one of ordinary skill in the art with appropriate reference to thespecification, including the drawings, as warranted.

1. A method of managing medical information comprising: receiving atleast one digital medical image in a format that is incompatible withviewing in an Internet web browser; predetermining without user input atleast one image display setting of the at least one digital medicalimage to permit medical diagnosis by the user of the at least onedigital medical image having the at least one image display settingapplied thereto; converting the at least one digital medical image usingthe predetermined at least one image display setting, wherein theconverted at least one digital medical image is compatible with viewingin an Internet web browser and retains its original resolution.
 2. Themethod of claim 1, wherein predetermining the at least one image displaysetting comprises determining a region of interest of the at least onedigital medical image; and cropping the at least one digital medicalimage around the region of interest.
 3. The method of claim 2, furthercomprising determining at least one of a brightness and a contrast ofthe region of interest to form at least one cropped and adjusted image.4. The method of claim 3, further comprising displaying a plurality ofcropped and adjusted images side by side in the Internet web browser. 5.The method of claim 2, further comprising grouping a plurality ofcropped images to form a cropped movie.
 6. The method of claim 5,further comprising determining at least one of the brightness and thecontrast of the plurality of cropped images to form a cropped andadjusted movie.
 7. The method of claim 5, further comprising determininga frame speed of the cropped movie to simulate real-time motion of anorgan.
 8. The method of claim 5, further comprising displaying aplurality of cropped movies side by side in the Internet web browser. 9.The method of claim 1, wherein predetermining the at least one imagedisplay setting comprises determining a magnification of the at leastone digital medical image.
 10. The method of claim 1, whereinpredetermining the at least one image display setting comprisesdetermining at least one of a brightness and a contrast of the at leastone digital medical image to form at least one adjusted image.
 11. Themethod of claim 10, further comprising displaying a plurality ofadjusted images side by side in the Internet web browser.
 12. The methodof claim 1, wherein predetermining the at least one image displaysetting comprises grouping a plurality of digital medical images to forma movie.
 13. The method of claim 12, further comprising determining atleast one of the brightness and the contrast of the plurality of digitalmedical images to form an adjusted movie.
 14. The method of claim 12,further comprising determining a frame speed of the movie to simulatereal-time motion of an organ.
 15. The method of claim 12, furthercomprising displaying a plurality of movies side by side in the Internetweb browser.
 16. The method of claim 1, wherein the at least one digitalmedical image originates from a plurality of medical devicesmanufactured by a plurality of manufacturers.
 17. The method of claim 1,wherein the at least one digital medical image comprises one of aplurality of medical imaging modalities.
 18. The method of claim 17,wherein the plurality of medical imaging modalities is associated withat least one of magnetic resonance imaging, echocardiographic imaging,nuclear scintigraphic imaging, positron emission tomography, and x-rayimaging.
 19. The method of claim 1, wherein the format comprises aplurality of formats wherein each of the plurality of formats isassociated with a predetermined one of a plurality of medical diagnosticimaging devices.
 20. The method of claim 1, further comprising storingthe converted at least one digital medical image in a database.
 21. Themethod of claim 1, further comprising posting the converted at least onedigital medical image for viewing in the Internet web browser.
 22. Themethod of claim 21, wherein the step of posting the converted at leastone digital medical image comprises embedding image tags in World WideWeb compatible pages, wherein the image tags reference the converted atleast one digital medical image.
 23. The method of claim 1, furthercomprising displaying the converted at least one digital medical imagein the Internet web browser on a remote computer in response to arequest from the remote computer.